UAT Test Plan — BC Dialing Application

Field	Value
Version	7.0
Date	March 11, 2026
Project	Bestway BC Development
Environment	Business Central Production

warning

This test plan covers the v2.4.0.0 release of the BC Dialing Application. Key changes: (1) Configurable batch cap for Job Queue processing — limits phone and email log records per run (default 50) to prevent unbounded processing, token expiry, and backlog cascading. (2) Immediate abandonment for permanent failures — 'Customer Not found' errors set Attempts = 3 immediately instead of wasting 3 retries. (3) Text field widening across 4 tables to resolve string length constraint errors on recording/transcript sync. (4) SecretText migration for UseReadySAS, eliminating AL0432 compiler warnings. Test Area 14 covers the new batch cap and abandonment behavior.

Overview

This test plan validates the BC Dialing Application extension for Microsoft Dynamics 365 Business Central. The extension integrates Nextiva phone and email events with BC Customer records. When an incoming call or email arrives, the extension looks up the Customer by phone number or email address. If no match is found, it creates a new Customer from the configured customer template (default: ECOMMERCE) and returns a URL to the Customer Card. A background Job Queue entry asynchronously syncs call summaries, recordings, and transcripts from the Nextiva Analytics API to Azure Blob Storage, linking each artifact to the Customer record.

v2.3.0.0 restructured the Job Queue codeunit (CU-60003) into a two-phase architecture that completes all HTTP I/O before any database writes, reducing Customer table lock duration from 15-40 seconds to under 1 second per record. It also externalized all hardcoded credentials and environment-specific values to the NextivaConfig table, added an upgrade codeunit for zero-touch deployment, fixed a Manual Sync regression, and resolved several data integrity issues.

v2.3.3.0 added 5 missing table permissions (Salesperson/Purchaser, Payment Terms, Currency, Country/Region, General Ledger Setup) to the inline Permissions property on Pages 80000, 80003, and CU-60000. Post-deployment telemetry confirmed that new customer creation was still failing — breadcrumb step 6 (ApplyCustomerTemplate) never fired, meaning the failure was happening inside Customer.Insert(true).

v2.3.4.0 added the remaining 13 standard Customer Templ. field tables (33 total). Post-deployment telemetry confirmed the failure was still occurring — the Dimension table (BC table 348, the dimension header table) was the final missing permission. It is accessed when DefaultDimension.Insert(true) fires during CopyDefaultDimensionsFromTemplate inside ApplyCustomerTemplate. The BC ORM validates the Dimension Code field's TableRelation against the Dimension table — this is not an explicit AL statement and was not visible to prior static code analysis. v2.3.5.0 adds Dimension = R, bringing the total to 34 tables.

v2.3.6.0 is a diagnostic release. Post-v2.3.5.0 telemetry shows the HTTP 403 rate on live Nextiva new customer creation is still 50-75%, while integration tests pass. The integration test uses BestwayBCAPI (D365 Full Access / SUPER), masking the actual Nextiva service account's permission context. v2.3.6.0 wraps NewCust.Insert(true) in a [TryFunction] procedure on Pages 80000 and 80003. On failure, BCDIALER-0021 logs the exact NavPermissionException text (including the specific table or codeunit name) to Application Insights before re-raising the error. Observable behavior from Nextiva is unchanged. The BCDIALER-0021 data will identify the root cause for v2.3.7.0.

Extension Object Summary

Object	ID	Extends	Purpose
API Page	80000	CustomerPhoneLog	Receives incoming phone call events. Looks up or creates Customer by Phone No.
API Page	80001	CustomerPhoneLog	Receives call-end events with Nextiva session ID for async processing.
API Page	80003	CustomerEmailLog	Receives incoming email events. Looks up or creates Customer by E-Mail.
API Page	80004	CustomerEmailLog	Receives email end-of-call events. Looks up Customer by E-Mail.
API Page	80010	NextivaConfig	Read-only config verification endpoint. Exposes boolean indicators for credentials.
Codeunit	60003	N/A	Job Queue processor — Phase 1 (HTTP/blob I/O) then Phase 2 (DB writes) for summaries, recordings, transcripts, and emails.
Codeunit	60004	N/A	Manual sync trigger — processes a single record via WorkItem ID.
Codeunit	60005	N/A	Upgrade codeunit — auto-populates NextivaConfig table during deployment.
Table	80003	N/A	NextivaConfig — stores credentials, URLs, template name, and SAS token.
Table Extension	60000	Customer	Secondary indexes on Phone No. and E-Mail for efficient lookups.

Prerequisites

• The BC Dialing Application extension v2.3.6.0 is deployed to the target environment.
• The upgrade codeunit (CU-60005) has run — verify via the Config API endpoint or the Nextiva Config Setup page (80007).
• The customer template configured in NextivaConfig (default: ECOMMERCE) exists in the target environment with a valid No. Series.
• The Azure Function forwarding Nextiva events is configured to point at the target BC instance.
• A test phone number and test email address are available that do NOT match any existing Customer records (for new-customer tests).
• A test phone number and test email address are available that DO match existing Customer records (for existing-customer tests).
• The Nextiva environment is accessible and can generate test call/email events.
• A Job Queue entry for CU-60003 is configured in the target environment (can be run manually for testing).
• The tester has access to the Customer Card, Customer Phone Log Viewer (Page 80005), Customer Email Log Viewer (Page 80006), Nextiva Error Logs (Page 80008), Nextiva Config Setup (Page 80007), and Nextiva Manual Sync (Page 80009).
• The deployment verification script (tools/verify_deployment.py) has been run and all checks pass.
• Access to Azure Application Insights for extension telemetry (App ID: 903e82d8) and environment telemetry (App ID: db343407). Azure CLI or portal access for KQL queries.

Test Area 1: Incoming Phone Call — New Customer

Requirement: When an incoming call arrives for an unknown phone number, the extension creates a new Customer from the configured template and returns the Customer Card URL.

Verify that the API page correctly creates a new Customer with the expected defaults and returns the correct URL and Customer No.

TC-1.1: New Customer Created from Phone Call

note

v2.3.3.0 critical fix: Prior to this version, this test case failed 65% of the time with HTTP 403 NavPermissionException due to 5 missing table permissions (Salesperson/Purchaser, Payment Terms, Currency, Country/Region, General Ledger Setup). This test validates the fix.

Step	Action	Expected Result
1	Trigger an incoming call event from the test phone number that does not match any existing Customer.	The API call returns successfully (HTTP 201).
2	Inspect the API response body.	The response includes a customerurl field containing a URL to the Customer Card and a customernum field containing the new Customer No.
3	Open the Customer Card using the returned URL.	The Customer Card opens. The Customer has Name = 'New Customer' and Phone No. matching the test phone number.

TC-1.2: Customer Template Defaults Applied

Step	Action	Expected Result
1	On the Customer Card from TC-1.1, inspect the posting group fields (Gen. Bus. Posting Group, Customer Posting Group, etc.).	All posting group fields match the defaults defined in the configured customer template (default: ECOMMERCE).
2	Inspect the Payment Terms Code and other template-driven fields.	All template-driven fields are populated with the template defaults.
3	Confirm the Phone No. field.	Phone No. matches the incoming call's phone number — it was not overwritten by the template.

TC-1.3: Phone Log Record Created

Step	Action	Expected Result
1	Open the Customer Phone Log Viewer (Page 80005).	The phone log list is visible.
2	Locate the log record for the test phone number.	A record exists with the correct Phone Number and Customer No. matching the newly created Customer.

Test Area 2: Incoming Phone Call — Existing Customer

Requirement: When an incoming call arrives for a phone number that matches an existing Customer, the extension returns the URL without creating a new Customer.

Verify that the API page finds the existing Customer and populates the Customer No. on the log record.

TC-2.1: Existing Customer Found by Phone Number

Step	Action	Expected Result
1	Trigger an incoming call event from the test phone number that matches an existing Customer.	The API call returns successfully (HTTP 201).
2	Inspect the API response body.	The customerurl field contains a URL pointing to the existing Customer Card. The customernum field contains the existing Customer's No.
3	Verify no new Customer was created.	The Customer count has not increased. No new 'New Customer' record exists.

TC-2.2: Customer No. Populated on Phone Log Record

Step	Action	Expected Result
1	Open the Customer Phone Log Viewer (Page 80005).	The phone log list is visible.
2	Locate the log record created by the call in TC-2.1.	The record's Customer No. field contains the existing Customer's No. — it is not blank.

Test Area 3: Incoming Email — New Customer

Requirement: When an incoming email arrives for an unknown email address, the extension creates a new Customer from the configured template.

Verify the email API page follows the same customer creation logic as the phone page.

TC-3.1: New Customer Created from Email

note

v2.3.3.0 critical fix: Prior to this version, this test case failed 74% of the time with HTTP 403 NavPermissionException due to the same 5 missing table permissions as TC-1.1. This test validates the fix on the email path.

Step	Action	Expected Result
1	Trigger an incoming email event from a test email address that does not match any existing Customer.	The API call returns successfully (HTTP 201).
2	Inspect the API response body.	The response includes customerurl and customernum fields.
3	Open the Customer Card using the returned URL.	The Customer has Name = 'New Customer' and E-Mail matching the test email address. Template defaults are applied.

TC-3.2: Email Log Record Created with Customer No.

Step	Action	Expected Result
1	Open the Customer Email Log Viewer (Page 80006).	The email log list is visible.
2	Locate the log record for the test email.	A record exists with the correct Email Address and Customer No. matching the newly created Customer.

Test Area 4: Incoming Email — Existing Customer

Requirement: When an incoming email arrives for an email address that matches an existing Customer, the extension returns the URL without creating a new Customer.

Verify that existing customer lookup and Customer No. population work for email.

TC-4.1: Existing Customer Found by Email

Step	Action	Expected Result
1	Trigger an incoming email event from a test email address that matches an existing Customer.	The API call returns successfully (HTTP 201).
2	Inspect the API response body.	The customerurl points to the existing Customer Card. The customernum contains the existing Customer's No.
3	Open the Customer Email Log Viewer. Locate the record.	The record's Customer No. field contains the existing Customer's No.

Test Area 5: EndMailCall — Customer No. Population

Requirement: When an email end-of-call event arrives, the extension looks up the Customer by email address and populates the Customer No. on the log record.

Verify that Page 80004 (EndMailCall) correctly populates Customer No. on email log records. This was an empty trigger prior to v2.3.0.0.

TC-5.1: EndMailCall Populates Customer No. for Known Email

Step	Action	Expected Result
1	Trigger an email end-of-call event for an email address that matches an existing Customer.	The API call returns successfully (HTTP 201).
2	Open the Customer Email Log Viewer (Page 80006). Locate the record created by the end-of-call event.	The record's Customer No. field contains the matching Customer's No. — it is not blank.

TC-5.2: EndMailCall with Unknown Email

Step	Action	Expected Result
1	Trigger an email end-of-call event for an email address that does NOT match any existing Customer.	The API call returns successfully (HTTP 201).
2	Open the Customer Email Log Viewer. Locate the record.	The record is created with a blank Customer No. — EndMailCall does not create new customers.

Test Area 6: Concurrent Access — No Lock Contention

Requirement: Incoming calls and emails must not block CS agents from editing or creating Customer records. Job Queue processing must not hold locks longer than 1 second per record.

Verify that the Phase 1/Phase 2 architecture and removal of LockTable() allow concurrent Customer operations without errors.

note

These tests require two simultaneous sessions: one triggering API calls or Job Queue processing and one manually editing Customer records. Coordinate timing so that the Customer Card edit is in progress while the other operation is running.

TC-6.1: Edit Customer Card During Incoming Call

Step	Action	Expected Result
1	Open a Customer Card in session A and begin editing a field (e.g., Name or Address).	The Customer Card is open and editable.
2	While session A has the Customer Card open, trigger an incoming call event in session B.	The API call completes successfully. No error is returned.
3	Return to session A and save the Customer Card.	The save completes without error. No 'information on this page is out of date' message appears.

TC-6.2: Create New Customer During Incoming Call

Step	Action	Expected Result
1	Begin creating a new Customer manually in session A (open a new Customer Card).	A new Customer Card is open for input.
2	While session A is filling in the new Customer, trigger an incoming call event in session B.	The API call completes successfully.
3	Complete and save the manually-created Customer in session A.	The insert completes without lock conflict or error.

TC-6.3: Edit Customer Card During Job Queue Processing

Step	Action	Expected Result
1	Ensure multiple pending phone log records exist (at least 3-5 records with sync flags = false).	Pending records are visible in the Customer Phone Log Viewer.
2	Open a Customer Card in session A and begin editing.	The Customer Card is open and editable.
3	Run the Job Queue entry for CU-60003 in session B.	The Job Queue begins processing.
4	While the Job Queue is processing, save the Customer Card in session A.	The save completes without error. No lock timeout or 'out of date' message.

Test Area 7: Job Queue Processing

Requirement: The Job Queue processor (CU-60003) asynchronously syncs call summaries, recordings, and transcripts from the Nextiva API to Azure Blob Storage using Phase 1 (I/O) then Phase 2 (DB writes).

Verify that pending phone and email log records are processed correctly by the Job Queue.

TC-7.1: Pending Phone Log Records Processed

Step	Action	Expected Result
1	Trigger one or more incoming calls that create phone log records with Nextiva session IDs.	Phone log records exist with SummaryUpdated = false, TranscriptUpdated = false, RecordingUpdated = false.
2	Run the Job Queue entry for CU-60003 (or wait for the next scheduled cycle).	The Job Queue completes without error.
3	Open the Customer Phone Log Viewer (Page 80005) and inspect the processed records.	SummaryUpdated, TranscriptUpdated, and RecordingUpdated are all set to true. The Attempts field has been incremented.
4	Open the matched Customer Card and inspect the Record Links.	Record Links exist for the summary, recording, and transcript — each pointing to an Azure Blob Storage URL.

TC-7.2: Pending Email Log Records Processed

Step	Action	Expected Result
1	Trigger one or more incoming emails that create email log records with Nextiva session IDs.	Email log records exist with InboundEmailUpdated = false and OutboundEmailUpdated = false.
2	Run the Job Queue entry for CU-60003.	The Job Queue completes without error.
3	Open the Customer Email Log Viewer (Page 80006) and inspect the processed records.	InboundEmailUpdated and OutboundEmailUpdated are set to true. The Attempts field has been incremented.

TC-7.3: Records with 3+ Attempts Are Skipped

Step	Action	Expected Result
1	Identify or create a phone log record with Attempts >= 3 and at least one sync flag still false.	The record exists with Attempts >= 3.
2	Run the Job Queue entry for CU-60003.	The Job Queue completes.
3	Inspect the record after processing.	The record was NOT processed — its sync flags and Attempts counter are unchanged from step 1.

TC-7.4: Job Queue Execution Time Under 5 Seconds

Step	Action	Expected Result
1	Ensure at least 3 pending phone log records exist.	Records are visible with sync flags = false.
2	Run the Job Queue entry for CU-60003.	The Job Queue completes.
3	Check Application Insights telemetry for the CU-60003 execution event (RT0018).	Total execution time is under 5 seconds for 3 records. Individual lock durations (Phase 2) are under 1 second per record.

Test Area 8: Manual Sync — Date-Based Path

Requirement: The Manual Sync page (80009) date-based path must use Phase 1 + Phase 2 from CU-60003, writing Record Links and updating processing flags.

Verify that the restructured date-based path correctly processes records end-to-end. This path was broken in the initial v2.3.0.0 restructure (called legacy stubs that only did Phase 1) and has been rewritten to call Phase 1 + Phase 2 directly.

TC-8.1: Date-Based Phone Log Sync

Step	Action	Expected Result
1	Open the Nextiva Manual Sync page (80009).	The page is visible with date and WorkItem ID input fields.
2	Enter a date range that includes pending phone log records. Leave WorkItem ID blank. Click Sync.	The sync process runs.
3	Open the Customer Phone Log Viewer and inspect the processed records.	SummaryUpdated, TranscriptUpdated, and RecordingUpdated flags are set to true.
4	Open the matched Customer Card and inspect Record Links.	Record Links exist for the summary, recording, and transcript — each pointing to an Azure Blob Storage URL.

TC-8.2: Date-Based Email Log Sync

Step	Action	Expected Result
1	Open the Nextiva Manual Sync page (80009).	The page is visible.
2	Enter a date range that includes pending email log records. Leave WorkItem ID blank. Click Sync.	The sync process runs.
3	Open the Customer Email Log Viewer and inspect the processed records.	InboundEmailUpdated and OutboundEmailUpdated flags are set to true. Record Links are written to the Customer.

Test Area 9: Manual Sync — WorkItem Path

Requirement: The Manual Sync page (80009) WorkItem path must process a single record via CU-60004.

Verify that the WorkItem-based sync processes a single record correctly.

TC-9.1: WorkItem-Based Phone Log Sync

Step	Action	Expected Result
1	Identify a pending phone log record's WorkItem ID (Nextiva session ID).	The WorkItem ID is documented.
2	Open the Nextiva Manual Sync page (80009). Enter the WorkItem ID. Click Sync.	The sync process runs for the single record.
3	Inspect the phone log record.	Processing flags are updated. Record Links are written to the matched Customer.

Test Area 10: NextivaConfig and Deployment Verification

Requirement: The upgrade codeunit (CU-60005) must auto-populate the NextivaConfig table during deployment. All config fields must be accessible via the Setup page and the Config API.

Verify that the config-driven deployment works correctly and all integration values are populated.

TC-10.1: Config Populated by Upgrade Codeunit

Step	Action	Expected Result
1	Navigate to the Nextiva Config Setup page (80007).	The setup page opens with a single config record.
2	Verify all fields are populated: BC Base URL, Customer Template, Nextiva Login URL, Nextiva AuthText, Azure Blob SAS Token.	All 5 fields have values. AuthText and SAS Token are masked.

TC-10.2: Config API Returns Correct Data

Step	Action	Expected Result
1	Query the Config API endpoint: GET /api/CambaySolutions/PhoneIntegration/v1.0/nextivaConfigs	The endpoint returns HTTP 200 with a JSON response.
2	Inspect the response body.	primaryKey = 'DEFAULT'. bcBaseURL, customerTemplate, and nextivaLoginURL contain the expected values. nextivaAuthTextConfigured = true. azureBlobSASTokenConfigured = true.
3	Verify that raw credentials are NOT exposed.	The response does not contain the actual AuthText or SAS Token values — only boolean indicators.

TC-10.3: Config Preserves Existing Manual Entries

Step	Action	Expected Result
1	Before deploying, manually set a custom BC Base URL in the NextivaConfig record via the Setup page.	The custom URL is saved.
2	Deploy (or re-deploy) the extension so the upgrade codeunit runs.	The deployment completes.
3	Open the Setup page and inspect the BC Base URL field.	The custom URL is preserved — the upgrade codeunit did not overwrite it.

TC-10.4: Deployment Verification Script Passes

Step	Action	Expected Result
1	Run the deployment verification script in config-only mode: ../../tools/venv/bin/python verify_deployment.py --config-only	The script reports PASS for the Config API check.
2	Run the full verification with credentials: ../../tools/venv/bin/python verify_deployment.py --nextiva-auth-text '...' --azure-sas-token '...'	All checks pass: Config API, Nextiva Auth, Azure Blob, Customer Template.

Test Area 11: Customer Template Application

Requirement: New customers created by the API pages must have the configured template defaults applied and retain the incoming phone number or email address.

Verify that the customer creation flow correctly applies the template without overwriting the contact information.

TC-11.1: Template Defaults Present on New Customer

Step	Action	Expected Result
1	Trigger an incoming call for a new phone number.	A new Customer is created.
2	Open the new Customer Card and inspect the Gen. Bus. Posting Group field.	The value matches the configured template's Gen. Bus. Posting Group setting.
3	Inspect the Customer Posting Group field.	The value matches the template's Customer Posting Group setting.
4	Inspect the Payment Terms Code field.	The value matches the template's Payment Terms Code setting.

TC-11.2: Phone Number Preserved After Template Application

Step	Action	Expected Result
1	Using the Customer created in TC-11.1, inspect the Phone No. field.	Phone No. matches the incoming call's phone number — it was NOT overwritten by the template application step.

TC-11.3: Email Preserved After Template Application

Step	Action	Expected Result
1	Trigger an incoming email for a new email address.	A new Customer is created.
2	Open the new Customer Card and inspect the E-Mail field.	E-Mail matches the incoming email address — it was NOT overwritten by the template application step.

Test Area 12: Error Handling

Verify system behavior under error conditions.

These tests document expected behavior when required configuration is missing or input data is invalid.

TC-12.1: Missing Customer Template

note

This test requires temporarily renaming or deleting the configured customer template. Restore it immediately after the test.

Step	Action	Expected Result
1	Temporarily remove the configured customer template from the sandbox.	The template is not findable by the Get() call.
2	Trigger an incoming call for a new phone number.	The API call returns an error (the specific error depends on BC's Get() failure behavior).
3	Restore the template.	The template is back in place.
4	Trigger another incoming call for the same phone number.	The API call succeeds — a new Customer is created normally.

TC-12.2: Job Queue Error Logging

Step	Action	Expected Result
1	Create a phone log record with an invalid or expired Nextiva session ID.	The record exists and is pending processing.
2	Run the Job Queue entry for CU-60003.	The Job Queue completes (the error is caught by the TryFunction wrapper).
3	Open the Nextiva Error Logs (Page 80008).	An error log entry exists for the failed record, showing the source No., session ID, and error message.
4	Verify the phone log record's Attempts counter was incremented.	Attempts increased by 1 despite the failure — the record will be retried up to the 3-attempt limit.

TC-12.3: Job Queue Continues After Single Record Failure

Step	Action	Expected Result
1	Ensure at least 2 pending phone log records exist — one with a valid session ID and one with an invalid session ID.	Both records are pending.
2	Run the Job Queue entry for CU-60003.	The Job Queue completes.
3	Inspect the record with the valid session ID.	Processing flags are set to true. Record Links are written.
4	Inspect the record with the invalid session ID.	An error is logged. Attempts incremented. The valid record was NOT affected by the failure.

Test Area 13: Telemetry and Post-Deployment Monitoring (v2.3.3.0)

Requirement: Extension-level and environment-level telemetry must confirm the permission fix is working and no regressions were introduced.

These tests validate the diagnostic infrastructure added in v2.3.1.0 (screen pop URL telemetry), v2.3.2.0 (breadcrumb telemetry), and the post-deployment monitoring for the v2.3.3.0 permission fix. All queries use Azure Application Insights.

TC-13.1: HTTP 403 Rate Drops to Near Zero

note

This is the definitive post-deployment verification for the v2.3.3.0 permission fix. Query environment-level telemetry (App ID: db343407) for RT0008 events. Pre-deployment baseline: 65% on Pag-80000, 74% on Pag-80003.

Step	Action	Expected Result
1	Query environment telemetry: traces | where customDimensions.eventId == 'RT0008' | where customDimensions.alObjectName in ('ReceivePhoneNumber', 'ReceiveEmail') | where customDimensions.httpStatusCode == '403' | where timestamp > ago(4h)	Zero or near-zero 403 events after deployment.
2	Compare the 201 count to total request count for the same objects and period.	Success rate should be near 100% for both phone and email paths.
3	If any 403 events remain, note the timestamp and proceed to TC-13.2 to identify the failing step.	Any remaining 403s are documented for further investigation.

TC-13.2: Breadcrumb Telemetry Shows Full Step Progression (BCDIALER-0020)

Step	Action	Expected Result
1	After a successful new customer creation (TC-1.1), query extension telemetry: traces | where customDimensions.eventId == 'ALBCDIALER-0020' | where timestamp > ago(1h) | order by timestamp desc	Events are present for all 7 steps: 1-TriggerEntry, 2-CustomerLookup, 3-NewCustStart, 4-PreInitCustomerNo, 5-PreInsert, 6-PreApplyTemplate, 7-PreModify.
2	Verify all 7 steps have the same Source dimension (Pag-80000 for phone, Pag-80003 for email).	Source is consistent across all steps.
3	Verify steps 5-7 include a CustomerNo dimension with a valid Customer No.	CustomerNo matches the customer created in TC-1.1.

TC-13.3: Screen Pop URL Telemetry (BCDIALER-0010)

Step	Action	Expected Result
1	Query extension telemetry: traces | where customDimensions.eventId == 'ALBCDIALER-0010' | where timestamp > ago(1h)	At least one event is present with Source, CustomerNo, BaseURL, and CustomerURL dimensions.
2	Verify the CustomerURL is well-formed: contains the correct tenant ID, environment, company, page number, and customer filter.	The URL follows the pattern in NextivaConfig's BC Base URL with the Customer No. substituted.

TC-13.4: No Config Fallback Events (BCDIALER-0001/0002/0003)

Step	Action	Expected Result
1	Query extension telemetry for fallback events: traces | where customDimensions.eventId in ('ALBCDIALER-0001', 'ALBCDIALER-0002', 'ALBCDIALER-0003') | where timestamp > ago(24h)	Zero events — NextivaConfig is being read successfully and no hardcoded fallbacks are active.
2	If any fallback events are found, identify which config field is empty and populate it via the Nextiva Config Setup page (80007).	All config fields verified populated.

TC-13.5: Job Queue Error Rate Reduced

note

ISSUE-14: Prior to v2.3.3.0, 91% of phone logs errored with 'Customer not found' because the 403 prevented customer creation. After the fix, new customer creation succeeds, and the Job Queue should find matching Customer records.

Step	Action	Expected Result
1	Query extension telemetry for the most recent BCDIALER-1001 (Job Queue completion) event.	The event shows phoneProcessed and emailProcessed counts.
2	Compare phoneErrored to the pre-deployment baseline (84/92 = 91% error rate).	The error rate is substantially reduced for records created after v2.3.3.0 deployment.
3	Query BCDIALER-5000 events from the last 4 hours.	The count of 'Customer not found' events should be lower than pre-deployment. Note: orphaned records from before the fix will continue to error until manually reprocessed.

TC-13.6: Insert Failure Diagnostic Telemetry Captured (BCDIALER-0021)

note

v2.3.6.0 diagnostic: This test confirms the TryFunction wrapper is capturing NavPermissionException detail on failed new customer creation attempts. The BCDIALER-0021 message field contains the exact failing object and permission type, which will drive the v2.3.7.0 fix.

Step	Action	Expected Result
1	Trigger an incoming call or email event from a phone number or email address not in BC (new customer path).	The API returns HTTP 403 (expected — v2.3.6.0 does not fix the root cause).
2	Wait 2-5 minutes, then query extension telemetry: traces | where customDimensions.eventId == 'ALBCDIALER-0021' | where timestamp > ago(15m) | project timestamp, message, customDimensions.Source, customDimensions.ErrorCode | order by timestamp desc	A BCDIALER-0021 event is present. The message field contains the full NavPermissionException text identifying the specific table or codeunit that caused the permission failure.
3	Record the message text and ErrorCode dimension from the BCDIALER-0021 event.	The exact failing object name is captured. Share with development for v2.3.7.0 fix targeting.
4	Confirm that BCDIALER-0020 step 5 ('calling Insert(true)') fired for the same event, and that step 6 ('Insert complete') did not fire.	Breadcrumb step 5 is present; step 6 is absent. This confirms the failure is inside Insert(true), and BCDIALER-0021 captures the reason.

Batch Cap and Abandonment

v2.4.0.0 introduces configurable batch caps for the Job Queue processor and immediate abandonment of records with permanent failures. These test cases validate that the batch cap limits processing per run, that permanent failures are abandoned without retries, and that the new configuration fields are accessible via the setup page and API.

TC-14.1: Phone Log Batch Cap Enforcement

Step	Action	Expected Result
1	Trigger the Job Queue entry for CU-60003 (or wait for the next scheduled run).	Job Queue run starts. BCDIALER-1000 telemetry event shows MaxPhoneLogs=50.
2	Wait for the run to complete. Check Application Insights for BCDIALER-1002.	A BCDIALER-1002 event is present with message 'Phone log batch cap reached (50)'. Processed + Errored counts sum to 50.
3	Verify that pending phone log records remain in the queue for the next run.	The next BCDIALER-1000 event shows PendingPhoneLogs reduced by ~50 from the previous run, not zero.

TC-14.2: Email Log Batch Cap Enforcement

Step	Action	Expected Result
1	Trigger the Job Queue entry for CU-60003 (or wait for the next scheduled run).	Job Queue run starts.
2	Wait for the run to complete. Check Application Insights for BCDIALER-1002.	A BCDIALER-1002 event is present with message 'Email log batch cap reached (50)'. Processed + Errored counts sum to 50.
3	Verify that pending email log records remain in the queue for the next run.	The next BCDIALER-1000 event shows PendingEmailLogs reduced by ~50, not zero.

TC-14.3: Immediate Abandonment — Customer Not Found (Phone)

Step	Action	Expected Result
1	Trigger the Job Queue entry for CU-60003.	Job Queue processes the record.
2	Check the CustomerPhoneLog record after the run completes.	Attempts = 3 (immediately abandoned, not incremented from 0 to 1).
3	Check Application Insights for BCDIALER-5002.	A BCDIALER-5002 event is present with message containing 'permanent failure' and the record's SourceNo and SessionID.
4	Trigger the Job Queue again.	The abandoned record is not processed again (Attempts >= 3 is excluded by the filter).

TC-14.4: Immediate Abandonment — Customer Not Found (Email)

Step	Action	Expected Result
1	Trigger the Job Queue entry for CU-60003.	Job Queue processes the record.
2	Check the CustomerEmailLog record after the run completes.	Attempts = 3 (immediately abandoned).
3	Check Application Insights for BCDIALER-5002 with SourceType = 'CustomerEmailLog'.	Event is present with the record's SourceNo and SessionID.

TC-14.5: Batch Cap Configuration — Setup Page and API

Step	Action	Expected Result
1	Open the Nextiva Config Setup page (80007).	A 'Job Queue Settings' group is visible with 'Max Phone Logs Per Run' and 'Max Email Logs Per Run' fields, both showing 50.
2	Change 'Max Phone Logs Per Run' to 25. Save the page.	Value is saved without error.
3	Query the Config API: GET /api/CambaySolutions/PhoneIntegration/v1.0/nextivaConfigs	Response includes maxPhoneLogsPerRun = 25 and maxEmailLogsPerRun = 50.
4	Restore the value to 50.	Value saved successfully.

TC-14.6: Text Field Widening — No Truncation Errors

Step	Action	Expected Result
1	Trigger the Job Queue entry for CU-60003 and let it process at least one phone log record.	Record processes successfully. No 'length of the string' errors in Nextiva Error Logs (Page 80008).
2	Check the Nextiva Error Logs viewer for any string length constraint errors.	No errors containing 'length of the string' are present for records processed after v2.4.0.0 deployment.
3	Verify the CustomerPhoneLog, CustomerEmailLog, and NextivaData tables via the respective viewer pages.	PhoneNumber, EmailAddress, and AssetType fields display their full values without truncation.